home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c++ / 388 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  6.4 KB

  1. Path: cs.mu.OZ.AU!bounce-back
  2. From: kanze@gabi-soft.fr (J. Kanze)
  3. Newsgroups: comp.std.c++
  4. Subject: Re: Standard string class
  5. Date: 20 Feb 96 05:41:50 GMT
  6. Organization: GABI Software, S`rl.
  7. Approved: fjh@cs.mu.oz.au
  8. Message-ID: <KANZE.96Feb19122908@gabi.gabi-soft.fr>
  9. References: <199602171134.LAA00305@kauri.vuw.ac.nz>
  10. NNTP-Posting-Host: munta.cs.mu.oz.au
  11. X-Original-Date: 19 Feb 1996 11:29:08 GMT
  12. In-Reply-To: robert.davies@vuw.ac.nz's message of 18 Feb 1996 02:14:33 GMT
  13. X-Auth: PGPMoose V1.1 PGP comp.std.c++
  14.     iQBFAgUBMSlgVuEDnX0m9pzZAQEvbQF+O9GDLsNuCxZPLoFedS3qg7tbYbtUmfhs
  15.     H9zdnG2N/GVLdHW946eHRfWVmY9Wrvvc
  16.     =0ckm
  17. Originator: fjh@munta.cs.mu.OZ.AU
  18.  
  19. In article <199602171134.LAA00305@kauri.vuw.ac.nz>
  20. robert.davies@vuw.ac.nz (Robert Davies) writes:
  21.  
  22. |> Here are some comments and a query about the standard string class. I am
  23. |> working from the January 96 working papers, but the comments also apply to
  24. |> the April 95 version of the standard.
  25.  
  26.  
  27. |> Reallocation
  28. |> ------------
  29.  
  30. |> Under the section on reserve the draft standard says that no reallocation
  31. |> of the storage takes place during insertions until the string reaches
  32. |> the length given by the last call of reserve. The standard does not say
  33. |> what insertion means. I assume it means append, +=, and possibly insert
  34. |> statements. Is this correct? If so the value returned by data() should
  35. |> remain valid following a call of append, += or insert if the string doesn't
  36. |> exceed the length set by reserve.
  37.  
  38. |> But this is conflict with the description of data() which says the value
  39. |> returned becomes invalid after any non-constant call to the string
  40. |> concerned.
  41.  
  42. |> Am I missing something or does this still need to be worked out?
  43.  
  44. |> ...recommendation: this be clarified
  45.  
  46. My feeling is that this is more a problem in getting all of the wording
  47. right than anything else.  Personally, I would like to see a global
  48. statement as to when iterators, references and pointers become invalid,
  49. rather than have the cases enumerated at each function.  Something along
  50. the lines of the following would seem to be the intent.
  51.  
  52.     An iterator into a basic_string, a reference returned by the member
  53.     functions at or operator[] or a pointer returned by the member
  54.     functions c_str and data, may be invalidated by any of the
  55.     following:
  56.  
  57.     1.    Calling a non-const member function on the string, unless
  58.         `reserve' has been previously called, in which case, they will
  59.         only be invalidated if the non-const member function causes
  60.         the string to become longer than the reserved size.
  61.  
  62.     2.    Calling either c_str or data.
  63.  
  64.     3.    Using the string as an argument to the member function swap.
  65.  
  66. I personally think that one could add assigning to the string, i.e.: an
  67. operator= undoes the effect of reserve.  There is nothing in the current
  68. draft that lets me think that this was the intent, however.
  69.  
  70. I would prefer seeing this defined purly in terms of validity of
  71. reference, without mention of possible reallocation.
  72.  
  73.  
  74. |> at and operator[]
  75. |> -----------------
  76.  
  77. |> The same comments apply here as applied to data() in my comments on
  78. |> reallocation.
  79.  
  80. |> Are we to assume that
  81. |> x[3] = 'a';
  82. |> as an example, may cause a reallocation, and so invalidate data()?
  83.  
  84. |> at and operator[] seem almost identical except that operator[] isn't
  85. |> required to check bounds. However, the const version of x[x.size()] is
  86. |> supposed to return traits::eos(), so if we store our strings without a
  87. |> trailing traits::eos() we will have to check bounds. Is this is what is
  88. |> intended?
  89.  
  90. Another interesting question is the meaning of "x[ x.size() ] = 'a'".
  91.  
  92. |> The constant version of operator[] returns a charT whereas the constant
  93. |> version of at returns a const_reference. What is the point of this 
  94. |> difference and what effect does it have?
  95.  
  96. |> ...recommendation: remove the requirement that x[x.size()] return
  97. |> traits::eos() and clarify the difference between operator[] and
  98. |> at.
  99.  
  100. |> Question: are we safe to assume that something = x[3] will use the constant
  101. |> version of the operator?
  102.  
  103. Definitly not.  Whether the const or non-const version will be used
  104. depends entirly upon whether x is const or not.
  105.  
  106.  
  107. |> reallocation again
  108. |> ------------------
  109.  
  110. |> Suppose I am right in thinking we can update a string with operator[], at,
  111. |> insert or append without causing reallocation.
  112.  
  113. As I interpret the intent, this is true if and only if you have called
  114. reserve.  These functions are non-const.
  115.  
  116. |>  Suppose also we are writing a string package with copy-on-write. Then
  117. |>  copy-on-write must be disabled on string for which data() etc has been
  118. |>  called. We need some way of telling a program that copy-on-write can be
  119. |>  reactivated - eg we are no longer interested in the value returned by
  120. |>  data(). Calling reserve() as I have defined above may be one
  121. |>  possibility.
  122.  
  123. Why does copy-on-write have to be disabled when data is called?  Any
  124. non-const function (which might trigger copy-on-write) should invalidate
  125. the pointer.
  126.  
  127. The one place I think copy-on-write must be disabled is precisely
  128. reserve.  Since by calling reserve, I have guaranteed no further
  129. allocations (no pointer invalidation) as long as the length remains
  130. inferior to the capacity.
  131.  
  132. |> ... recommendation: some way be found for allowing a user to re-instate
  133. |> copy-on-write.
  134.  
  135. This is the purpose behind my suggestion that assignment `undo' the
  136. effects of reserve.
  137.  
  138. It would probably also be worth mentioning that copy on write cannot be
  139. used if the allocators of the two strings compare different.  I think
  140. that this is implicit in the current wording, and I'm not quite sure how
  141. to put it into legalese, either, but I think it must be clear;
  142. otherwise, what is the purpose of having the allocators?  (Note that
  143. this is not a problem for string and wstring, since they both use the
  144. default allocator, and all instances of the default allocator compare
  145. equal.)
  146. -- 
  147. James Kanze           (+33) 88 14 49 00          email: kanze@gabi-soft.fr
  148. GABI Software, Sarl., 8 rue des Francs Bourgeois, 67000 Strasbourg, France
  149. Conseils, itudes et rialisations en logiciel orienti objet --
  150.               -- A la recherche d'une activiti dans une region francophone
  151. ---
  152. [ To submit articles: try just posting with your news-reader.
  153.                       If that fails, use mailto:std-c++@ncar.ucar.edu
  154.   FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html
  155.   Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html
  156.   Comments? mailto:std-c++-request@ncar.ucar.edu.
  157. ]
  158.